-
Notifications
You must be signed in to change notification settings - Fork 576
fix(integrations): google-genai: reworked gen_ai.request.messages extraction from parameters
#5275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(integrations): google-genai: reworked gen_ai.request.messages extraction from parameters
#5275
Conversation
… if mime_type and file_uri are present (Cursor comment)
…i-report-image-inputs
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Ai
Other
Bug Fixes 🐛Integrations
Litellm
Other
Documentation 📚
Internal Changes 🔧Release
Other
🤖 This preview updates automatically when you update the PR. |
…i-report-image-inputs
| if isinstance(function_response, dict): | ||
| tool_call_id = function_response.get("id") | ||
| tool_name = function_response.get("name") | ||
| response_dict = function_response.get("response") or {} | ||
| # Prefer "output" key if present, otherwise use entire response | ||
| output = response_dict.get("output", response_dict) | ||
| else: | ||
| # FunctionResponse object | ||
| tool_call_id = getattr(function_response, "id", None) | ||
| tool_name = getattr(function_response, "name", None) | ||
| response_obj = getattr(function_response, "response", None) or {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen this .get() vs getattr pattern a lot in our AI integrations. Feels like introducing a helper function that would try both at once would potentially deduplicate a lot of code.
Not something that needs to be done in this PR, mostly thinking out loud.
…AI messages Add transform_content_part() and transform_message_content() functions to standardize content part handling across all AI integrations. These functions transform various SDK-specific formats (OpenAI, Anthropic, Google, LangChain) into a unified format: - blob: base64-encoded binary data - uri: URL references (including file URIs) - file: file ID references Also adds get_modality_from_mime_type() helper to infer content modality (image/audio/video/document) from MIME types.
…rmats Replace inline_data and file_data dict handling with the shared transform_content_part function. Keep Google SDK object handling and PIL.Image support local since those are Google-specific.
Add dedicated transform functions for each AI SDK: - transform_openai_content_part() for OpenAI/LiteLLM image_url format - transform_anthropic_content_part() for Anthropic image/document format - transform_google_content_part() for Google GenAI inline_data/file_data - transform_generic_content_part() for LangChain-style generic format Refactor transform_content_part() to be a heuristic dispatcher that detects the format and delegates to the appropriate specific function. This allows integrations to use the specific function directly for better performance and clarity, while maintaining backward compatibility through the dispatcher for frameworks that can receive any format. Added 38 new unit tests for the SDK-specific functions.
Replace generic transform_content_part with the Google-specific transform_google_content_part function for better performance and clarity since we know Google GenAI uses inline_data and file_data formats.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| return { | ||
| "type": "blob", | ||
| "mime_type": mime_type, | ||
| "content": BLOB_DATA_SUBSTITUTE, | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: When processing object-based inline_data or PIL.Image objects, the returned blob dictionary is missing the modality field, creating an inconsistent data structure compared to other data types.
Severity: HIGH
Suggested Fix
In _extract_part_content, update the logic for handling object-based inline_data and PIL.Image objects. Add the modality field to the returned dictionary by calling get_modality_from_mime_type(mime_type), similar to how file_data is handled. This will ensure all blob data structures are consistent.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: sentry_sdk/integrations/google_genai/utils.py#L343-L347
Potential issue: The function `_extract_part_content` creates an inconsistent data
structure for blob data. When handling object-based `Part` objects with `inline_data`
containing bytes (lines 337-348) or `PIL.Image` objects (lines 418-422), the returned
dictionary omits the `modality` field. However, when processing dictionary-based
`inline_data` or `file_data`, the `modality` field is correctly included using the
`get_modality_from_mime_type` helper. This inconsistency can lead to downstream
processing errors if other parts of the system expect a standardized blob format that
always includes `modality`.
Did we get this right? 👍 / 👎 to inform future reviews.
Description
Previously we only extracted only text parts were extracted. Now the full range of possibilities are covered.
Issues
Closes https://linear.app/getsentry/issue/TET-1638/redact-images-google-genai